The present invention relates in general to the field of computers and similar technologies, and in particular to software utilized in this field.
An Integrated Development Environment (IDE) is computer software used to help computer programmers develop code. IDEs normally include a source code editor (either a text or modeling-language-based editor in a first window of a User Interface—“UI”), a compiler and/or interpreter (underlying software not shown in the UI), build-automation tools (including modeling languages) and a debugger (in a second window in the UI). The UI often includes a class browser, an object inspector and a class hierarchy (tree) diagram for use with object oriented software development.
Visual editors are the tool of choice for designing application UI's. Such visual editors utilize modeling-language-based editors as described above. UI elements are added to the editor and are manipulated by selecting a visual element (which is modeling-language-based) and changing its properties.
For visual editing tasks in which content is multi-layered in nature (e.g., table oriented content), visualization and selection of individual elements in the content containment hierarchy becomes increasingly difficult as the complexity of the containment hierarchy increases. For example, in most What-You-See-Is-What-You-Get (WYSIWYG) visual editors, the visualizations of container objects are usually small, often only a few pixels tall. These visualizations are this small because this is how the object will be displayed at runtime, or, if they are not displayed at all at runtime, because of limited real estate on the screen during the code editing process. Oftentimes, there are multiple levels of containers (e.g., tables within tables), wherein there is very little space between containers. That is, the containers may have a little as one pixel between them, or they may actually be on top of each other (no pixels between them). Therefore, the hotspot for selecting one container versus another may only be a matter of one or a few pixels. For example, consider the IDE window 100a shown in FIG. 1a 
View 100a, shown in FIG. 1a, depicts a Table A as a 3×3 table. The top left cell of Table A contains a Table B, which is visually obscured in a visual display by Table A. Table B, as shown in view 100b of FIG. 1b, is a 2×2 table. The top left cell of Table B contains Table C, which is also a 2×2 table, but which is obscured by Table B (and Table A). Trying to select the top left cell of Table A versus the top left cell of Table B, for example, is very difficult. As depicted, the very top left corner of view 100a contains borders for each table, as well as the top row of each table, as well as the top left cell of each table. Thus, there is no way to distinguish between the borders of the table, the row or the cell, because they appear to be the same. Furthermore, at runtime in and IDE environment, only one border is visible. Nonetheless, during development, a particular (single) table, row or cell you may need to be selected, but cannot due to the obscuring problem just stated. Furthermore, many “What-You-See-Is-What-You-Get” (WYSIWYG) editors will not display any visual representation of some containers (in order to adhere to WYSIWYG display), making their visual selection even more difficult (as shown, for example, FIG. 2a discussed below).
Similar issues exist for non-IDE environments, including visual editors used in engineering, business software and productivity applications to create presentations, diagrams, models and engineering blueprints. Such non-IDE environments include software applications such as PowerPoint®, Visio®, workflow editors, architecture design software and Computer Aided Design (CAD) software.